Previous attempt invoked vs_installer.exe with an explicitly-quoted
installPath; it bailed with exit 87 (invalid parameter).  Two changes:

- Use `Installer\setup.exe` (the VS bootstrapper) and fall back to
  vs_installer.exe.  setup.exe is what Microsoft documents as the
  bootstrapper for modify operations.
- Pass --installPath as a bare PowerShell argument (let Start-Process
  quote it), drop the manual backtick-quotes that confused the parser.

Also stop trusting the bootstrapper's exit code — VS Installer returns
non-zero in several benign cases.  Verify by checking that MSBuild can
see the v140 platform toolset:
  ${env:ProgramFiles(x86)}\MSBuild\Microsoft.Cpp\v4.0\V140
If that path exists after the modify call, the toolset is registered
and Python's PCbuild can use it.

Previous attempt passed the bootstrapper arguments as a PowerShell
array; Start-Process then concatenated them without re-quoting, so
`C:\Program Files\Microsoft Visual Studio\18\Enterprise` was parsed
as separate positional arguments and the installer rejected the call
with exit 87.

Build the command line as a single string with embedded double quotes
around $VS_INST_LOC.  Start-Process forwards that verbatim, the
installer sees a properly-quoted --installPath, and the modify
operation proceeds.

Verified against the real Visual Studio Installer (4.x) on a Windows
11 box: passing --wait makes the bootstrapper bail before parsing
anything else with "Option 'wait' is unknown" and exit code 87 — the
mystery exit-87 we kept hitting in CI.

--quiet already runs the modify synchronously, and Start-Process -Wait
in PowerShell still ensures we don't return until the bootstrapper
process exits.

Tested locally: the full install_vc_build.ps1 -CICD now reports
"Ensuring v140 toolset is installed: Already present" on an existing
VS install, and the standalone modify call returns exit 0.

After v140 install succeeded, Python 3.11.15 PCbuild started failing
on the windows-latest runner with:

    \ucrt\wchar.h(443): error C2440: 'initializing': cannot convert
    from 'int' to '__m128i'

Two related causes, both fixed here:

- The bootstrapper was warning "Cannot find package:
  Microsoft.VisualStudio.Component.Windows81SDK in product graph" —
  that component was removed in VS 2022+ / VS 18.  No SDK was actually
  installed alongside v140, so PCbuild fell back to the runner's only
  SDK (Win11 SDK 10.0.26100.0), whose <wchar.h> uses SSE intrinsics
  that v140 chokes on.
- Even with an older SDK installed, MSBuild auto-picks the newest one
  unless told otherwise.

Install `Windows10SDK.19041` (Win10 SDK 2004, the latest known to pair
cleanly with v140 and Python's PCbuild) and pin the build step to it
via `WindowsTargetPlatformVersion`.

windows-latest has rolled to VS 18 (a.k.a. VS 2026), whose VS Installer
product graph no longer exposes pre-26100 Windows SDKs by component
name.  We need v140 + an older Windows SDK to compile Python 3.10/3.11
PCbuild (newer SDKs put SSE intrinsics in <wchar.h> that v140 chokes
on with C2440), but on VS 18 we can't get there:

  Warning: Cannot find package: Microsoft.VisualStudio.Component.Windows10SDK.19041
           in product graph.
  error MSB8036: The Windows SDK version 10.0.19041.0 was not found.

windows-2022 still ships VS 2022 with multiple Windows SDKs (10240,
19041, 20348, 22621, 26100), so v140 + the env-var pin to 10.0.19041.0
works there.  Pin both build_windows and the matching verify
test_windows to that image until a path forward exists for VS 18.

The install-v140/SDK-19041 helper in install_vc_build.ps1 and the
WindowsTargetPlatformVersion env var stay in place: on windows-2022 the
v140 check is a no-op (it's pre-installed), and the env var pins
MSBuild to the SDK that v140 expects.